Collaborative product taxonomy instantiation

ABSTRACT

A method forms a collaborative product taxonomy instantiation by starting with or defining a base taxonomy instantiation and collaborating between trading parties to negotiate a collaborative product taxonomy instantiation. The taxonomy instantiation comprises a set of characteristics and values of a desired product. The method assigns a set of characters to the collaborative product taxonomy instantiation. The method uses the set of alphanumeric characters in an electronic trade exchange between a buyer software application and a seller software application. The seller software application may determine whether it has a product that is equivalent to the collaborative product taxonomy instantiation.

BACKGROUND

The following disclosure relates to systems for buying and sellingdirect materials and stockable Maintenance, Repair and Operations (MRO)materials. “Direct materials” are raw materials and components used tomanufacture products. “Stockable MRO materials” are replacement parts orspare parts for components, products, assemblies and subassemblies ofcapital equipment used by manufacturing companies. Some enterprises useelectronic commerce (e-commerce) technology, such as e-selling ande-procurement applications, to buy and sell direct materials andstockable MRO materials. This buying and selling can occur in (a) B2B(Business to Business) scenarios where a single buying entity engages ine-commerce with a single selling entity, and (b) public or privatetrading exchange-based scenarios where multiple buying entities engagein e-commerce with multiple selling entities.

Both direct materials and stockable MRO materials are often modeled asinternal part numbers (IPNs) (also called part identifiers, productnumbers or product identifiers) in both buyers' and sellers' computersystems. An enterprise computer system's product lifecycle management(PLM) component may generate part numbers internally. Part numbers ofdirect and stockable MRO materials in behind-the-firewall (BTF)enterprise computer systems carry information that trigger enterpriseand e-commerce system application logic, such as pricing, costing,planning, and inventory management. Internal part numbers generally haveno inherent meaning outside of the firewall (OTF) of the enterprisesystems landscape.

Outside the firewall (OTF) means outside an enterprise's computersecurity system. Inside the firewall (ITF) or Behind the Firewall (BTF)is inside an enterprise's computer security system.

A key obstacle in business-to-business (B-to-B or B2B) e-commerce inpublic and private sales and procurement exchanges (PTXs) is thatparticipating purchasing and selling entities do not understand eachother's product identifiers, i.e., part numbers. For example, a companythat makes computers may use its own internal part number (IPN) for apart to be purchased. A supplying manufacturer may have a ManufacturersPart Number (MPN) for a form, fit, function equivalent part. A supplyingdistributor may have its own Vendor Part Number (VPN) for a form, fit,function equivalent part. Use of heterogeneous, independently generatedproduct identifiers by purchasing and selling entities for materialsthat may be FFF (Form, Fit, Function) equivalent results in semanticdisconnects between the purchasing and selling entities during automatede-commerce processes. This semantic disconnect requires intervention andparticipation of technical experts in buying and selling entities todetermine whether parts that buyers want to buy and parts that sellerswant to sell are form, fit and function equivalent. This participationand manual intervention by experts to determine FFF equivalency slowsdown and adds to the cost of industrial commerce that involves directand stockable MRO materials.

FIG. 1 illustrates examples of buy side applications 100, sell sideapplications 102 and a plurality of procurement private trade exchange(PTX) based applications 110. The PTX applications 110 may include ademand aggregation application 112, a request for quotation(RFQ)/Quotation application 114, and an auctioning/bidding application116.

In the private procurement trading exchange (PTX) 110, a procuringentity 100 may deploy multiple buy-side enterprise systems 104A-104C.Alternatively, the systems 104A-104C may represent computer systems ofmultiple enterprises. The procuring entity's systems 104A-104C may havemore than one part number for parts that are form fit function (FFF)equivalents. Similarly, for the multiple sell-side participants106A-106C, each sell-side participant 106 may have a different partnumber for parts that are form, fit, and function equivalents.

Buyers 104A-104C on the buy side 100 and sellers 106A-106C on the sellside 102 may have multiple part numbers for form, fit and function (FFF)equivalent products. A part's form, fit and function (FFF) equivalent isdefined by a set of specifications, which may be represented as ataxonomy instantiation. For example, a computer manufacturer 104B on thebuy side 100 may identify an electronic component, e.g., a dynamicrandom access memory (DRAM), which the manufacturer 104B wishes to buy,with a part number “4711” in the manufacturer's enterprise computersystems. A supplier 106C on the supply side 102 may internally call itsDRAM product “WXYZ” in the supplier's computer systems. These internalpart numbers (IPNs) may be linked to each company's internal softwareapplications, such as financials, inventory, sales, etc.

When manufacturers 104A-104C buy components and materials from suppliers106A-106C, it is important that the suppliers' parts (e.g., “WXYZ”) beform, fit and function (FFF) equivalents to the part (e.g., “4711”)required by a buyer 104. While there might be thousands of DRAM productsavailable in the global electronic marketplace, none or few products maybe a FFF equivalent to what the buyer 104 needs.

A computer manufacturer 104 may wish to electronically solicit potentialadditional sources of supply for DRAM by using an e-procurement systemto send RFQs to potential new suppliers 106A-106C around the world. Aproblem arises when the potential sources of supply, i.e., companies106A-106C that manufacture or distribute DRAM, do not recognize “4711”since each supplier 106 has its own part numbers for DRAM products. Asupplier 106 receiving an electronic request for quotation (RFQ) 114 forpart number “4711” would have no way of knowing what the part number“4711” represents, unless additional information is available.Similarly, a buyer 104 receiving a solicitation to buy “WXYZ” from asupplier 106C would have no way of knowing whether the “WXYZ” part is anFFF equivalent to “4711.”

Free form product specifications (text) that accompany a product or RFQdo not solve the problem because specifications developed by the buyer104 may not map directly to specifications developed by a seller 106.Free form text may also require people to read and process the text.

The product semantics disconnect (different part number problem)constrains buyers 104A-104C from finding additional sources of supply inthe global electronic marketplace, and constrains suppliers 106A-106Cfrom electronically promoting their products to buyers 104A-104C.Especially in exchange environments 110, heterogeneous part numberingconstrains applications like demand aggregation 112, electronicauctioning and bidding 116 and electronic RFQ/quotation exchanges 114,because these applications may require a single part number to process.

In addition, as illustrated in FIG. 1, a large or diverse buying entityon the buy side 100 may have different part numbers in differentdivisions 104A-104C for FFF equivalent items due to mergers,acquisitions and legacy part numbering systems. Also, specifications forthe different products may have been developed at different times bydifferent engineers and may not be consistent.

Today, the problem of determining FFF equivalency is addressed throughprocedures and additional human-to-human communications between buyers104A-104C and sellers 106A-106C. But the procedures and additionalhuman-to-human communications limit the speed and efficiency of thebuy/sell process, and fail to take advantage of the potential vastproductivity gains to be realized through e-commerce on the World WideWeb (WWW).

Supply Chain FIG. 2 illustrates an example of a supply chain 200. Thesupply chain 200 includes manufacturers 202, franchised componentdistributors 204, independent component distributors 206, originalequipment manufacturers (OEMs) 208, value added distributors (VAD) 210,value added resellers 212, an end customer 214, component manufacturers216, component brokers 218 and contract manufacturing services (CMS) orcontract electronics manufacturer (CEM) 220. FIG. 2 also depicts the useof the Electronic Component (EC) catalog taxonomy (ECCT) and theInformation Technology (IT) catalog taxonomy (ITCT) segments of aversion of the RosettaNet Technical Dictionary (RNTD).

A CEM is a provider of manufacturing services to original equipmentdesigners (OEDs). Component manufacturers may send part specificationsto the OED. The OED sends documents to the CEM, including the OED'sapproved manufacturer parts list (AMPL) and “customer (from the CEM'sperspective) bill of materials (BOM) (see FIG. 11).” The CEM's customerthe OED, and from the OED's perspective, customer BOMs are OED-createdBOMs using the OED's Internal Part Numbers (IPNs). Cross reference ofcustomers' AMPLs and BOMs provide information to the CEM as to whichparts (e.g., MPNs and/or VPNs) can be purchased in order to manufactureequipment for the OED, based on the OED's BOM.

The OEMs 208 and CEMs 220 may buy components from the distributors 204,206 and component brokers 218, who buy the components from thesemiconductor manufacturers 202 and electronic component manufacturers216. In some cases, the OEM 208 may buy components directly from theelectronic component manufacturers 216. CPTI may enable OEMs 208, OEDsand CEMs 220 to more easily buy directly from component manufacturers216, rather than purchasing via distributors 206.

In some cases, distributors 206 provide the added value of helpingbuyers identify sources of supply or sellers identify customers for FFFspecific components. Distributors 206 may create knowledge of which partnumbers may be FFF equivalents.

The semantics disconnect problem may compound at each level of theglobal industry supply chain 200. For example, a manufacturer's partnumber (MPN) of a component manufacturer 202 (e.g., semiconductormanufacturer) is often given different vendor part numbers (VPNs) bydistributors 204, 206 and component brokers 218. A manufacturer's partnumber (MPN) is a product ID given by a manufacturer to a component madeby the manufacturer. The MPN is assigned by the component's originalmanufacturer, e.g., manufacturer 202. A variation of this is where anMPN's manufacturer is not the original manufacturer, but manufacturers aFFF equivalent to the original MPN, and assigns an MPN that is arecognizable variant of the original manufacturer's MPN.

A vendors' part number (VPN) is a product ID of a component assigned bya vendor. Technically, the vendor could be the manufacturer, andtherefore the VPN could be the MPN. Typically, the term “vendor” appliesto distributors, who may assign their own part numbers because thedistributor/vendor may resell components from multiple manufacturersthat are FFF equivalent and may sell these under one VPN identifier.

From a buying organization's perspective, an internal part number (IPN)may be a product identifier for a procured, stockable (inventoried)material or component. For example, in the SAP R/3 Enterprise ResourcePlanning (ERP) system, an IPN may represent a “material master” object,which is a master record or representation of a product. The materialmaster may have a raw or purchased material type. The material masteridentifier may be the same as a part ID or a product identifier. If anitem is stockable, like direct materials or stockable MRO, then the itemmay be identified in the system as a material master before anytransactions for the material item can be performed by the system. Thesystem needs information from the material master to trigger applicationlogic. A material master may be separated into different “views,” suchas a basic data view (e.g., with description and unit of measure), asales view (e.g., with sales prices and sales unit of measure), aplanning view (e.g., with reorder point and MRP parameters), a costingview (cost), etc.

A “material master” in SAP's R/3 system may be known by another term inother enterprise or e-selling or e-procurement systems. For example, inSAP's e-procurement system Enterprise Buyer Professional (EBP), partnumbers created in the system are called “product masters.” In stockablemaintenance, repair and operations (MRO) environments, the IPN is theidentifier (ID) under which procured equipment spare part components arestocked. In direct material environments, the IPN is used to managestocked materials and is also the ID for procured components in a billof materials (BOM).

Original equipment manufacturers (OEMs) 208 are original designers andmanufacturers of equipment, which can be assembled from procuredmechanical, electrical and passive components. Original equipmentmanufacturers (OEMs) 208 have internal part numbers (IPNs) forcomponents in their bills of materials (BOMs). Each of these IPNs may belinked to an approved manufacturers list (AML) (known in SAP R/3 as anApproved Manufacturers Part List (AMPL), and in some other systems, anAVL (Approved Vendors List)) (see AMPL 1124 in FIG. 11). The AMPL 1124contains multiple FFF equivalent MPNs, VPNs and/or EPNs 1126A-1126C thathave been pre-approved for purchase, typically by a procurementengineer, when a net requirement exists for the IPN to which the AMPLhas been linked. By definition, each MPN, VPN, or EPN in the AMPL isinterchangeable or an FFF equivalent to the IPN, i.e., share a set ofcommon specifications or attributes. All approved part numbers in theAMPL should function properly when used in the product manufacturedunder a BOM, or when used as a replacement part in the product.

A contract manufacturer (CM) 220 in FIG. 2 may need to maintain BOMs ofIPNs with associated AMPLs for multiple OEM customers in the CM'ssystem. The OEM customers can easily have different IPNs for items thatare FFF equivalent. These IPNs from different OEMs 208 will havedifferent AMPLs, which may often have a high degree, but not total,overlap. For example, an AMPL for one OEM's IPN may contain some MPNs orVPNs which are also included in AMPLs for other OEMs IPNs.

In manufacturing industries, net materials requirements planning (MRP)is performed on the IPNs in BOMs. A purchase order (PO) is generated forthe IPN and the PO also contains one of the FFF-equivalent approvedparts in the AMPL 1124. This allows the selling company to know whichpart number (e.g., the approved part number) is selected from the AMPL.A selected MPN 1126B is received into the buyer's inventory as aspecific part number IPN3 1112, i.e., the identity of the MPN 1126B maybe lost with the receipt-to-stock transaction. A purchasing company willoften buy different approved parts from the AMPL 1124 with differentPOs. Thus, multiple, different approved parts 1126A-1126C may be carriedphysically in inventory under the IPN3. All of the approved parts1126A-1126C in the AMPL 1124 should be FFF equivalents to the IPN3 1112.Otherwise, the approved parts 1126A-1126C may not function within theproduct (e.g., a computer) manufactured from components in the product'sBOM structure 1100.

The term “approved” in AMPL indicates that each part listed in the AMPLhas been tested and “approved” as being a FFF equivalent to thespecifications or attributes of the IPN. Two MPNs with similarspecifications are not necessarily FFF equivalent, since thespecifications may not be precise enough to ensure that the parts areFFF equivalent. Thus, there is a need for an “approved” manufacturer'sparts list (AMPL). Parts are usually designated as approved aftertesting to make sure they function properly in the equipment withinwhich they are used.

GTIN

One proposed standard part numbering solution is the Global Trade ItemNumber (GTIN). A GTIN represents a specific manufactured product. TheGTIN is a 14-character, non-intelligent, numeric identifier thatincludes a packaging code, a company code, a sequential identifier and a“check digit.” It is identical to the EAN/UCC-14. There is a one-to-onecorrespondence between a GTIN and a specific manufactured product. AGTIN may be assigned sequentially by a manufacturer or a consortium.GTINs were designed for buyers and sellers to use the same part numberthroughout the supply chain, rather than each using their own,self-assigned part numbers. Thus, GTINs would streamline productinformation flow.

GTINs are limited because there is no semantic relationship between apart's GTIN and the part's FFF. If a buyer submitted an RFQ with aparticular GTIN, the seller would not be able to easily or quicklyderive the part's FFF to determine whether the seller had a product tooffer. So while buyers can use seller's GTINs after they become known toa seller, a buyer RFQing a new supplier does not yet know the newseller's GTIN for the part that the buyer wants, or indeed whether thenew seller has such a product. Nor can the new seller determine from thebuyer's internal part number what the buyer wants to buy.

RosettaNet (see www.rosettanet.org) is a consortium of 400+ companies inthe high tech and electronics industry. RosettaNet states that where aone-to-many relationship exists between a buyer's IPN and possible FFFequivalent part numbers from suppliers, the Approved Manufacturers List(AML) or Approved Manufacturers Part List (AMPL) may be used. The buyercan continue to use the same IPN, rather than using a supplier's GTIN asthe buyers IPN. This is desirable for manufacturers because if thebuying manufacturing company created IPNs using the sellers' GTINs, thebuying manufacturing company may have multiple FFF equivalent IPNs. Thismay result in the buyer's MRP system generating a net requirements for agiven IPN even though there might be available inventory of another FFFequivalent IPN. Thus, manufacturers may desire to use the AMPL ratherthan GTINs.

RosettaNet allows for use of GTINs for distributors and use of AMPLs formanufacturers. RosettaNet has defined a Partner Interface Process (PIP)for the AML, aka AMPL (Approved Manufacturers Parts List). The IPN withAML is more conventionally used in enterprise systems by electronicsmanufacturing companies than GTINs.

SUMMARY

The present application relates to the process of providing aCollaborative Product Taxonomy Instantiation (CPTI) as part of acollaborative taxonomy, which may be a component of a Cross ApplicationProduct Taxonomy Management (xPTM) system.

A CPTI of the invention eliminates semantic disconnects in directmaterials and stockable MRO supply chains, which are caused byheterogeneous or disparate product identifiers, by providing a unifyingidentifier understood by the various parties to a communication. Forease of reference the unifying identifier will be referred to as anExchange. Part Number (EPN) that may be an alphanumeric value. The CPTIprocess recognizes that trading partners (e.g., business enterprises)within commerce communities have different, mutually incomprehensible,part numbers for products that may be equivalent e.g., have the sameform, fit and function (FFF). For ease of description FFF will be usedto define equivalents for purposes of grouping objects under one EPN.CPTI enables trading partners and trading communities within globalindustry supply chains to more readily identify sources of supply(buy-side perspective) and potential customers (sell-side perspective)using e-commerce technology.

Furthermore, the present invention recognizes that developing theinstantiations in a taxonomy requires collaborative discussions ornegotiations between parties. Typically the discussions or negotiationstake place electronically, e.g. over the internet, to allow more thantwo parties to easily access and propose changes to an instantiation,e.g., through the use of a collaborative folder or other exchangetechnology. As such, the present invention proposes using an existingbase taxonomy as the starting point for collaboration. Eachinstantiation, defines an object (e.g., DRAMs) having certain attributesor parameters (e.g., voltage tolerances, temperature tolerances,footprint, speed, capacity), wherein at least some of the attributeshave values associated with them (e.g., 5V, 80 degrees Celsius, etc.)The collaboration may relate to different aspects of the instantiation;e.g. to sub-grouping objects, adding or deleting attributes or adding ordeleting value ranges.

xPTM involves the linking of the collaborative taxonomy to otherapplications, such as back end systems, to be integrated into theprocurement, planning or other aspects of an enterprise logic system. Assuch xPTM may be used by design engineers (e.g., with PLM applications),and planners (e.g., with Supply Chain Management (SCM) applications) andby maintenance (Plant Maintenance (PM) applications). CPTI may be usedwith e-Commerce systems like e-procurement, e-Sales, Private Exchanges(PEXs or PTXs) and electronic bidding and auctioning applications.

Thus CPTI refines the concept of using standard taxonomies (e.g., theRosettaNet Technical Dictionary (RNTD, eClass or UNSPSC codes)(RosettaNet, Partner Interface Process, PIP, are trademarks ofRosettaNet, a non-profit organization) to communicate FFF by adding atleast two acts: (a) at least one buyer and seller collaborate to refine,customize and instantiate at least once a baseline standard taxonomy,i.e., create a collaborative product taxonomy instantiation, and (b)assigning an exchange part number (EPN) to represent the resultingcollaborative taxonomy instantiation. The collaboration participantsassociate material master data with the resulting EPN in theirrespective e-commerce and e-selling systems and back office enterprisesystems. EPNs resulting from the CPTI collaboration process are machinesensible after entry as material masters in the participants' systems.Machine sensible part numbers enable the e-commerce dialogue between thee-selling and e-procurement systems to be fully automated. There is noneed for intervention of experts to interpret and manually enter thedata in the recipients' systems, which is usually necessary whentaxonomy instantiations, rather than recognizable part numbers, are sentfrom system to system.

Generally speaking, the World Wide Web has some limitations due to thesemantic disconnects between communicating parties. Differences interminology and other semantic differences provide a significant hurdleto free communication between parties. The term Semantic Web has beenused to describe a Web where the semantic differences have beenaddressed. This state of Utopia has, however, not been realized in thepast. The CPTI process discussed in the embodiment below may, on theother hand, be considered as a specific industrial application ofSemantic Web ontology and taxonomy concepts. It will therefore beappreciated that, while the particular embodiment relates to semanticdifferences between buyers and sellers in naming their products, theinvention is equally applicable to addressing other semantic disconnectsby providing a collaborative environment and by mapping thecommunicating parties' terminologies to common key terms. For purposesof conciseness, a particular application of the invention will bediscussed in detail below. The common key terms that serve as the linkbetween the communication parties' terminologies will be referred toExchange Part Numbers (EPNs). EPNs refer to a set of numbers, letters, aset of alphanumeric characters, or, in the case of Chinese, Japanese, orother non-alphabet based characters, a set of one or more characters.Since the common key words (in this case referred to as EPN) need notnecessarily be viewable by a user, the EPNs could even be undefinedcharacters (binary strings that are commonly used simply for the purposeof translating from one set of serial numbers to another). Typically,however, an EPN that is viewable and understandable by human users ispreferable since it can be displayed to the communicating parties asconfirmation that they are dealing with a product with the sameattributes. In the embodiment discussed below, the EPN may enableautomated e-procurement and e-selling of direct material components andstockable MRO materials via e-commerce documents in scenarios wherebuyers and sellers have different BTF part numbers for FFF equivalentitems.

Buyers and sellers may be unable to understand each other's internalpart numbers (IPNs), vendor part numbers (VPNs), manufacturer's partnumbers (MPNs) and customer part numbers (CPNs).

Resolution of heterogeneous system product ID disconnects may enableelectronic auctioning applications.

In an on-line collaboration to negotiate a CPTI the method may compriseselecting from a taxonomy a first set of attributes and values for adesired component; posting the first set of attributes and values to acollaborative environment; accessing a second set of attributes andvalues via the collaborative environment, wherein at least some of theattributes or values or both attributes and values in the second set aredifferent from the first set; forming a taxonomy instantiationcomprising at least some of the attributes and values from the first andsecond sets of attributes and values; and assigning a set of charactersto the taxonomy instantiation.

Another aspect relates to a method comprising: forming a collaborativeproduct taxonomy instantiation, the taxonomy instantiation comprising aset of characteristics or attributes of a desired product; assigning aset of characters to the collaborative product taxonomy instantiation;and using the set of characters in an electronic trading exchangeapplication between at least one buyer and at least one seller.

Another aspect relates to an electronic commerce exchange configured tocommunicate with at least one product procurement software applicationand at least one product sales software application. The procurementsoftware application has a first internal product identifier. The salessoftware application has a second internal product identifier. Theinvention associates a unifying identifier or key to the first andsecond internal product identifiers

Another aspect relates to an electronic catalog comprising a pluralityof collaborative taxonomy instantiations, each collaborative taxonomyinstantiation comprising a plurality of characteristics and values, eachcollaborative taxonomy instantiation being linked to an exchange partnumber.

Another aspect relates to an electronic commerce document configured tobe sent over the Internet between a component buyer and a componentseller. The electronic commerce document includes an exchange partnumber. The exchange part number is associated with a collaborativeproduct taxonomy instantiation.

Another aspect relates to a method comprising: accessing a catalog ofcollaborative taxonomy instantiations; and using an exchange productnumber to find its collaborative taxonomy instantiation withpre-determined characteristics.

CPTI may provide many advantages or benefits. For example, purchasingcompanies may be able to establish additional sources of supply, whichmay enable the purchasing companies to procure materials with shorterlead times and for less cost as a result of having a broader range ofalternative suppliers. The purchasing company may manufacture productsfrom procured components. The shorter lead times and/or lower costsresulting from CPTI may enable the purchasing company to in turn selltheir manufactured products for lower prices or to deliver assembledproducts in less time.

Selling companies may be able to more easily identify additionalcustomers, which may enable them to increase sales volume.

The details of processes and systems are set forth in the accompanyingdrawings and the description below. Other features and advantages willbe apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates examples of a buy side, a sell side and procurementprivate trade exchange (PTX) based applications.

FIG. 2 illustrates a high tech industries supply chain and levels of thechain where the RosettaNet RNTD might be used as a basis for a catalogtaxonomy.

FIG. 3A illustrates a collaborative product taxonomy instantiation(CPTI) process.

FIG. 3B illustrates an example of an SAP PLM System collaborative folderas an environment for collaboration on a baseline taxonomy as describedin FIG. 3A.

FIG. 4 illustrates an example of multiple buy-side systems, exchangeapplications and sell-side systems where an exchange part number (EPN)is mapped to multiple FFF equivalent BTF part numbers.

FIG. 5 illustrates an example of integrating CPTI into a broader set offunctions as part of a cross application product taxonomy management(xPTM) system.

FIG. 6 illustrates the Cross Application Product Taxonomy Management(xPTM) process of FIG. 5 with a view of user roles.

FIG. 7 illustrates examples of RosettaNet Technical Dictionary (RNTD)version 1.4 classes, property sets, properties and property valueexpressions.

FIG. 8 illustrates a market exchange scenario with buyers, a marketplaceand sellers using exchange part numbers (EPNs) as generated by a CPTIprocess.

FIG. 9 illustrates mapping of buyer part numbers and seller part numbersto EPNs resulting from a CPTI process in order to bridge the semanticsdisconnects that would otherwise result from buyers and sellers havingdifferent part numbers for parts which are FFF equivalents.

FIG. 10 illustrates CPTI catalog related terms, including a taxonomy, ataxonomy instantiation, a search engine and a part number associatedwith the taxonomy instantiation.

FIG. 11 illustrates a bill of materials (BOM) for a parent item (e.g., acomputer) and an approved manufacturer's parts list (AMPL) for acomponent of the parent item.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

An industry-specific (high tech) example of Collaborative ProductTaxonomy Instantiation (CPTI) is described herein. The principles ofcollaborative product taxonomy instantiation, however, are equallyapplicable to any manufacturing industry, such as automotive, aerospace,consumer goods, apparel, etc.

Taxonomies

A “taxonomy” is a set of classes, characteristics and values used todescribe and catalog a plurality of objects (also called items,components, parts, products or materials). As used herein,“characteristics” in a taxonomy may also be called properties,attributes or specifications. The objects may be grouped into a “class”or “category.” A taxonomy may also be called a “classification schema”or a “catalog search schema.”A “product taxonomy” is a taxonomy used tocategorize a set of products.

Several industry consortiums are developing taxonomies. For example,RosettaNet (see www.rosettanet.org) has developed an openly available,standard taxonomy (or classification schema) in response to the productnumbering problem. RosettaNet's standard taxonomy is called theRosettaNet Technical Dictionary (RNTD). Computer and electronicscompanies may use the RNTD to describe and catalog electroniccomponents, semiconductors, Information Technology (IT) equipment andother products.

FIG. 7 illustrates examples of RNTD classes 700, property sets 702,properties 704 and property value expressions 706. RNTD version 1.4contains approximately 741 classes, 2,647 properties and 610 propertysets. An example class is Memory—Dynamic RAM (DRAM), which includesseven property sets (e.g., “Semiconductor Package,” “SemiconductorCommon Set”) and 105 properties, (e.g., “High Level Output Voltage”).RNTD property value expressions include a property domain (e.g.,“integer” or “string”) and property units (e.g., “volt” or “kilogram”),and others.

Standard taxonomies may serve two complementary purposes:

-   -   Provide a common meta-language in e-commerce for buyers and        sellers to describe products and services in mutually        comprehensible terminology; and    -   Use as search schemas in electronic catalogs (procurement or        sales catalogs), which enable users to find product part numbers        through selection or specification of product attributes.

As used herein, an “electronic catalog” (“e-catalog”) is acomputer-based catalog and does not refer to traditional paper catalogs.

An “exchange catalog” is a catalog accessible by computers of allenterprises within a trading community.

Electronic catalogs may already exist, typically at a seller's web siteor behind the firewall as an internal catalog on the buy side. But aseller's catalog taxonomy and a buyer's catalog taxonomy currently maynot be compatible (may not map category/attribute/value tocategory/attribute/value). The idea of using standard catalogschemas/taxonomies (to make it easier for buyers and sellers toprecisely understand whether what is being sold is/is not the same aswhat is being bought) has not been widely implemented.

Taxonomies in a procurement private trading exchange (PTX) may provide abasis for:

-   -   Classification of internal part numbers (IPNs) and        identification of part numbers that are FFF equivalent to other        part numbers (resulting, for example, from mergers), which        enables demand aggregation and excess inventory reduction;    -   Representation of common attributes of the IPN and the MPNs        and/or VPNs in an AMPL.

Taxonomies in a sales PTX may provide a basis for creating a sales PTXcatalog search schema.

Multiple Part Numbers on the Buy Side and Multiple Part Numbers on theSell Side

There are at least two e-commerce examples with multiple part numbers onthe buy side 100 (FIG. 1): (a) a multi-division legal purchasing entityhas multiple form, fit, function equivalent IPNs, which may be true ofan enterprise operating a private procurement exchange 110, and (b) inthe case of a public exchange, where multiple buy-side exchangeparticipants collaborate in order to be able to aggregate demand.

A company operating a private procurement exchange (PTX) may havemultiple FFF equivalent IPNs in their BOMs because:

-   -   The company's technology infrastructure may not be able to        determine whether a required FFF equivalent IPN already exists        before creation of a new IPN. For example, existing IPNs may not        have all been categorized in a schema/taxonomy to enable a        search to determine whether a required IPN exists.    -   Procedures to search and determine whether FFF equivalent IPNs        exist before creating a new IPN may not be in place or may not        be followed.    -   The company operating the PTX may have acquired other companies        and still be using the acquired companies' legacy ERP systems.    -   The company operating the PTX might be a Contract Electronics        Manufacturer (CEM) with multiple customers (OEDs that purchase        contract manufacturing services from the CEM), where the        customers (OEDs) have products containing FFF equivalent        components with different part numbers. For example, two        different computer OEDs may always have different IPNs for FFF        equivalent parts since they may use different techniques or        systems to generate part numbers for their IPNs.    -   There may be a key difference between the IPN/MPN relationship        in B2B scenarios and in exchange-based scenarios. In B2B        scenarios, there may be a one-to-many relationship between the        IPN and various MPNs and VPNs (assuming no acquisitions,        adequate procedures and technology). In public exchange-based        scenarios, where there are multiple buy-side exchange        participants, there is always a many-to-many relationship        between buy side IPNs and sell side MPNs and VPNs.

Demand Aggregation

The multiple IPN scenario makes it difficult to aggregate demand toarrive at quantity for auctioning/bidding and RFQ/Quotation scenarios.For example, in FIG. 1, individual MRP planning runs to calculate netrequirements in the back-end systems would result in separate plannedrequirements for the FFF-equivalent IPNs 1234, 4711 and 7890, such as:

1234=100

4711=100

7890=100

Seller Understanding of IPN

A related problem occurs in RFQ/Quotation scenarios: either in single(or multiple buying companies) to single (or multiple selling companies)B2B scenarios. A recipient 106 of the RFP/RFQ will by definition notunderstand the procurement entity's IPN. So even if demand for themultiple FFF equivalent IPNs were aggregated under a single part number(for example 300 units of IPN 4711), the seller 106 would not be able torespond the RFQ with a Quotation. The seller 106 will not understand thepart number “4711.”

Taxonomy Instantiations

The following excerpt from a RosettaNet document entitled “(PIP) PartnerInterface Process 2A9/10 Query/Respond Technical Product Information,”illustrates a taxonomy used as meta-language. The excerpt is an exampleof an e-commerce dialogue between a purchasing company (e.g., a buyer104 in FIG. 1) and a group of distributors or sellers 106A-106C. Thebuyer seeks to identify possible sources of supply (i.e., distributorsor sellers 106A-106C) for a DRAM computer component (represented in theRNTD as class XJA644 (Memory—Dynamic RAM)).

Query Sent by Purchasing Company/OEM:

RosettaNet Class=“XJA644”

Voltage=“5”

Rated Maximum Power=“GT 4 AND LT 6”

Pin Count=“24”

Response Sent by Distributor 1:

RosettaNet Class=“XJA644”

Voltage=“5”

Rated Maximum Power=“GT 4 AND LT 6”

Operating Temperature=“50”

Is Generic=“1”

Pin Count=“24”

Response Sent by Distributor 2:

RosettaNet Class=“XJA644”

Technology=“CMOS”

Voltage [min]=“1.1”

Voltage [max]=“5.5”

Rated Maximum Power=“GT 4 AND LT 6”

Operating Temperature [min]=“45”

Is Generic=“1”

Pin Count=“20”

“E-Commerce documents” may be in XML format and are transmitted via theInternet to a recipient. An “e-commerce dialogue” is an exchange ofdocuments, for example as specified in a RosettaNet Partner InterfaceProcess (PIP). For example, Buying company A sends an RFQ (Request forQuotation) document with specifications for a product to Selling CompanyZ. Selling Company Z may respond with a Quotation document for aspecific product. Buying company A may respond with a Purchase Orderdocument for the specific product. Selling company Z may respond with anOrder Confirmation document for the specified product. Selling company Zmay send an Advanced Shipment Notification (ASN) document for thespecified product.

The dialogue above illustrates the use of RNTD taxonomy “instantiations”to define what is needed by a buyer and what is available from sellers.A “taxonomy instantiation” includes a set of properties (or attributesor characteristics) selected from a class (or category) in a basetaxonomy, e.g., RNTD, and values selected or specified for theattributes. For example, the attributes/properties above were selectedfrom seven property sets and 105 properties associated with the DRAMclass in RNTD. This use of the RNTD as a commonly understoodmeta-language enables the members of the trading community to engage ina commerce dialogue. But this dialogue is not yet an automated dialogue.

Human involvement may be necessary in an e-commerce document exchangewhen the receiving system cannot automatically process the incomingdocument. This could be for several reasons. For example, the documentmay contain a part number not recognized by the recipient's system(because a material master had not been previously created).Alternatively, the document could be in the wrong format, i.e., theincoming document contained a taxonomy instantiation that is not machinesensible by the recipient's system because of one of several reasons.Most likely, the recipients system may not have transactions like“Import taxonomy instantiation” and “Search via classification (a.k.a.taxonomy).” Another reason is the recipient may not have categorizedparts into the taxonomy. Another reason is the sender and the recipientmight have used different taxonomies.

If the buyer organization 104 (FIG. 1) had used its internal part number(IPN) “4711” to represent DRAM without additional information ordialogue, the sellers 106A-106C would not have been able to respond. Inmost cases, the part number alone does not convey the requiredinformation, and would therefore require additional dialogue.

A buying organization 104 may not know the selling organization's MPNfor the buyer's FFF equivalent IPN. If both commerce partners use thesame standard schema/taxonomy, the buyer 104 may provide the seller 106with a set of attribute values as a means of specifying what the buyer104 would like to purchase.

The example above describes a dialogue where a single buying companycorresponds with multiple distributors to determine whether thedistributors have an available electronic component that is form, fit,function (FFF) equivalent to what is required by the buyer. The dialogueincludes only seven of the 105 properties included in the class for DRAMclass XJA644. Rarely would a buyer need to specify values for all 105 ofthe properties for DRAM to describe a DRAM to a degree of specificityrequired by the buyer to determine that the manufacturers offering mightbe FFF equivalent.

The PIP dialogue example above does not actually describe acollaborative taxonomy instantiation process (described below) butrather an exchange of information initiated by a buyer to identifysources of supply, probably to populate an AMPL.

A key difference between the PIP dialogue above and the collaborativetaxonomy instantiation process described below is that the PIP dialoguedoes not result in a collaborative taxonomy instantiation. Thecollaborative taxonomy instantiation process (below) precedes the actualbuy/sell process. The collaborative taxonomy instantiation process(below) enables the buy-sell process to function in a much moreautomated way since an exchange part number (EPN) is linked to acollaborative attribute/value set, based on a standard taxonomy, whichrepresents an agreed upon degree of specificity to represent FFFequivalency.

In one configuration, the collaboration process may also occur via aweb-accessible PLM Collaborative Folder (FIGS. 3B and 5), where asegment of the RNTD in the spreadsheet format (also available atrosettanet.org) is accessed and collaboratively modified by tradingpartners. The trading partners highlight the most relevant properties ofa product taxonomy, and optionally specify additional properties, thenspecify values for the properties. In another configuration, the tradingpartners may access a web-accessible catalog maintenance environment,where the baseline taxonomy has been imported and the created as acatalog search schema.

Shortcomings of Standard Taxonomies

While standard taxonomies, such as the RNTD taxonomy-based approachspecified by RosettaNet PIP2A9/10, may provide a basis for addressingthe different part numbering problems in a supply chain, they may notsolve the problem.

Reasons for the problem include the following:

-   -   Taxonomy instantiations are not generally “machine sensible” by        computers.

So if the buyer's e-procurement system is able to transmit a taxonomyinstantiation (at least as free form text contained in a field within aRequest for Quotation (RFQ) e-commerce document), the sellers' e-sellingsystem would not be able to automatically process the RFQ e-commercedocument for a product represented using this technique. Nor could thebuyer's e-procurement system automatically process quotation documentsfrom the seller's system containing taxonomy instantiations like theexamples shown above.

One exception in a “mySAP” Sales and Distribution (SD) module of SAP'sR/3 ERP system, which may be able to import and process a salesconfiguration instantiation received from an SAP Customer RelationshipManagement (CRM)/Internet Pricing Configurator (IPC)'s SalesConfiguration Engine (SCE). SAP's R/3 Sales and Distribution moduleincludes sales order entry and management, including pricing, taxcalculation, availability checking, and triggering of accountsreceivable. SAP R/3's SD component can receive a taxonomy instantiationfrom another SAP component, the Sales Configuration Engine (SCE).

But this system is not operative in the e-commerce environment of CPTI,because the SAP components SD and SCE are homogeneous systems, notheterogeneous. Both SD and SCE components can process the same so-calledproduct configuration Knowledge Base (KB), which comes from the samemaintenance environment (e.g., PIN). This is not true in a tradingcommunity environment where the participants likely have heterogeneoussoftware and/or computer systems.

Even if a trading partner's system could automatically send (most can,at least as text) taxonomy instantiations, and even if a recipients'system could automatically process taxonomy instantiations (most systemscannot initiate an electronic catalog search to find a productcorresponding to the FFF expressed in the taxonomy instantiation), itwould still be necessary for the commerce partners to have catalogedtheir products using the same taxonomy as the transmitted taxonomyinstantiation (e.g., an instantiation based on the RNTD). Realistically,many enterprises have not done this massive cataloging project, or atleast have not cataloged a critical mass of their products for the samerelease version of the same taxonomy at the same time. This is because:

-   -   Taxonomies evolve. For example, the RNTD is at version 2.0 and        still evolving. Even when the buyers and sellers use a standard        taxonomy, like RNTD, there is the issue of multiple versions.        The current version 2.0 differs substantially from its        predecessors, e.g., version 1.4.    -   Taxonomies can be very deep and very broad. For example, the        RNTD version 1.4 has approximately 741 classes, 2,647        properties, 610 property sets and an unlimited number of        property values. It may be prohibitively expensive for a        manufacturer with a large product range to catalog all of its        products at all levels of detail of the taxonomy.

The RosettaNet PIP 2A9/10 approach of exchanging taxonomyinstantiations, rather than part numbers, may not be useable by alle-commerce and enterprise systems. Even if the receiving system iscapable of automatically receiving and processing a taxonomyinstantiation (i.e., populate attribute value sets in transactions like“Import taxonomy instantiation” and “Search via Classification”), itwould still be necessary for part numbers in the receiving system tohave been previously categorized into the taxonomy, so that the “Searchvia Classification” transaction would yield a result.

To use a taxonomy and assign a part number, for example in SAP's R/3Enterprise system, there is a view of a material master (used torepresent a product, or part number, or part indentifier in the BTFenterprise system) called the Classification View. First, the taxonomyshould be replicated in the ERP system. In R/3, this may be done via aseries of transactions:

-   -   Create characteristics (e.g., “Resistance Value”) and values        (e.g., “2200 Ohms, 1100 Ohms”)    -   Create class (e.g., DRAM)    -   Link the characteristic Resistance Value to the class DRAM (the        characteristic values are linked automatically since the values        are previously linked to the characteristic)    -   Create the classification view of a material master.

In a transaction called “Maintain Material Classification,” a view inthe material master, a user classifies a material=DRAM=“4711” into theclass/attribute/value set for the “DRAM” class. The user specifies thename of the class, e.g., “DRAM.” Upon entry of the class name into thetransaction, the system displays all of the characteristics and valuesfor the class. For example, the characteristic “Resistance Value” andthe values “2200 Ohms, 1100 Ohms.” If DRAM “4711” uses 2200 Ohms, thenthe user selects the characteristic value “2200 Ohms” (as well as allother relevant characteristics and values for the material 4711). Theuser then “saves” this class instantiation, which is linked to thematerial.

The saved class instantiation enables the user to find the material/partnumber for DRAM 4711. The user enters the class “DRAM” in thetransaction “Search via Classification,” or selects from a drop-downlist. The system automatically displays all characteristics and valueslinked to the class (in this case, the characteristic Resistance Valueand the values 2200 Ohms, 1100 Ohms. If the user wants to find the partnumber for a DRAM component requiring 2200 Ohms, the user clicks on thecharacteristic value “2200 Ohms,” which prompts the system to list thepart number for the 2200 Ohm DRAM component, which in this example is4711.

The example above only discusses linking characteristics and values tothe class “DRAM” which is linked to the material component “4711.” Theexample describes the set-up required to find a material (e.g., DRAMcomponent 4711) via its characteristics, using a catalog search engineor an internal classification system, like the one that exists in SAP'sR/3.

The example above is a description of a simple catalog taxonomy. Indirect materials procurement, it may be necessary for a procured item tobe FFF equivalent to what is needed by the buyer, and the taxonomy maybe much more complex. For example, the RNTD version 1.4 DRAM class has105 properties. Each property can have a very wide range of allowablevalues. Thus, a buying entity's process of categorizing all of its partsinto a taxonomy, like the RNTD, may be a massive project with massivecosts, especially when considering parts databases of tens or hundredsof thousands of parts.

While some companies may recognize the benefit of using taxonomies, theymay also recognize that the benefit can only be realized if the buyingcompanies' sell-side trading partners have also categorized all of theirparts into the same schema. Generally, industries may recognize thevalue of using taxonomies, but have not done it yet because it is a veryexpensive process. The ROI potential of this process may not besignificant until a critical mass of companies within an industry havecategorized their parts. As of today, only a very small percent ofcompanies may have made the investment.

Even in high tech, which is generally recognized as being much moreadvanced in the standards arena than other industries, companies maywait before adopting taxonomy standards because the standards are stillevolving. For example, RNTD has already been revised several times. If abuying company categorized all parts based on RNTD 1.4, and a sellingcompany categorized based on RNTD 2.0, a schema/taxonomy instantiatedand generated by the buying company may not be automatically processedby the selling company. Even if the selling company's system had thenecessary “Search via classification” transaction or used an electroniccatalog, the selling company cannot automatically process the taxonomyinstantiation because each of the two revisions could havecharacteristics and/or values that the other did not.

The supply-chain disconnect caused by different part number semanticsmay require phone calls and e-mails in order for buyers and sellers todetermine the Form, Fit, Function specifications. These actions fail totake advantage of the potential ROI of e-selling and e-procurementsystems in all environments, including public and private procurementand sales exchanges, as well as electronic auctioning and biddingsystems.

Even if buyers and sellers agree to use a standard taxonomy, and evenwhen their respective e-selling and e-procurement systems can send andreceive taxonomy instantiations (class, property, value combinations),typically these systems require a part number to trigger theapplications. This means that a recipient of an RFQ based on a taxonomyinstantiation, for example, would still be required to “manually”examine the taxonomy instantiation, and then search with tools to see ifa part number exists in the seller's parts database with the FFFdescribed in the taxonomy instantiation sent by the buyer. This isbecause the seller's system likely would not be able to automaticallytrigger a taxonomy based search for a part number corresponding to theform, fit, function described in the taxonomy instantiation.

This manual search step breaks the efficiency of the automatede-commerce dialogue, even in the best case, where the seller uses thesame taxonomy as the buyer—as the RosettaNet industry consortiumenvisions with the RNTD.

Buy- and sell-side e-commerce systems can automatically process partnumbers, if the part numbers have been created as master data within thee-commerce systems. However, where buying or selling entities receive ane-commerce document containing a part number where the part number hasnot previously been defined as master data, the document recipient'ssystem will not be able to automatically process the document.

The Internet offers the prospect of either buyers or sellers being ableto more easily contact a larger number of prospective customers orvendors. But the problem of buyers and sellers not being able toautomatically process e-commerce documents where the trading partners'part numbers are not known compounds with each additional potentialtrading partner.

Therefore buyers and sellers require an efficient way to determine FFFequivalency without extraneous dialogue between buyers and sellers.

There are two related techniques to represent FFF equivalency:representation as a taxonomy/schema instantiation and representation asa part number derived from or linked to a taxonomy/schema instantiation.

The first technique involves representing the commerce object (e.g., anelectronic component) as a taxonomy/schema instantiation. For example,the following may be a taxonomy instantiation in an XML document format:

<Resistance Value>220 Ohms</Resistance Value<CircuitDesignator>IndependentCircuit</Circuit Designator> <TRTolerance>+/− 5% and TCR +/− 100 PPM/C</TR Tolerance> <PackagingType>Tube </Packaging Type> <Number of Terminals>16</Number ofTerminals> <Package Style>QSOP</Package Style> <Product Class>Thin Filmon Silicon</Product Class>

A problem with this technique is that generally very few e-commercesystems can automatically process documents containing schemainstantiations, although many e-commerce systems can process documentscontaining part numbers, if the part number has previously been definedas master data.

Information needed by e-selling and e-procurement applications istypically linked to a part number. The R/3 part number length may be 18characters in length. Other systems may support longer part numbers.Only very few (if any) e-commerce systems would be able to supportproduct representations as long as a schema instantiation for atechnical product.

A heterogeneous systems environment is a trading exchange environmentwhere the buy-side and sell-side participants use a variety of packagedsoftware and/or in-house developed systems. In such environments, thereare no scenarios where the participant's e-commerce and back officesystems would generally all be able to process schema/taxonomyinstantiations in the way that they are able to process part numberstoday. On the other hand, many business application systems use thetechnique of linking part numbers to additional information that ismeaningful to a system, e.g., e-selling, e-procurement, supply chainmanagement, Enterprise Resource Planning (ERP) systems.

This leads to the possibility of using a technique where FFF equivalencycan be modeled as a part number: either as a part number derived from aschema instantiation, or as a sequentially-generated, internallyassigned number linked to a schema instantiation. For example, thesequentially generated, internally assigned number may be generated byR/3 PLM and then linked to a schema instantiation using Stockable Typeor Product Type creation capability with PLM under R/3's VariantConfiguration capability.

Collaborative Product Taxonomy Instantiation (CPTI)

CPTI is a collaborative solution that resolves disconnects related todifferent product part numbers and removes constraints to e-commercewithin trading communities. CPTI incorporates standard taxonomy conceptsand addresses the above-mentioned problems. To address theabove-mentioned problems, the CPTI process may include enhancing andcustomizing a baseline standard taxonomy; creating an instantiation(specifying attributes and attribute values); and assigning an exchangepart number (EPN) to represent the instantiation in e-commercedocuments.

FIG. 3A illustrates a collaborative product taxonomy instantiation(CPTI) process.

I. In a block 330 of FIG. 3A, the CPTI process includes a pre-commerceprocess of one or more buyer(s) and seller(s) agreeing on a baselinetaxonomy and creating a collaborative taxonomy instantiation by adding,changing and/or deleting form, fit and function characteristics andvalues. Thus, the buyer(s) and seller (s) agree upon a level of form,fit and function) equivalency.

A “collaborative product taxonomy instantiation” is a collaborativecreation of a taxonomy instantiation based on an agreed upon taxonomywhere the trading community members agree that the instantiationrepresents a level of Form, Fit, Functional equivalence.

II. In a block 332, the entity operating the exchange (e.g., buyingenterprise) designates an exchange part number (EPN) to represent thecollaborative taxonomy (C-Tax) instantiation. The EPN may comprise a setof any number of alphanumeric characters or symbols. The CPTI EPNcorresponds to an instantiation of a class. Thus, an exchange partnumber (EPN) is a part number linked to a collaborative taxonomyinstantiation agreed to by trading community participants. It will beappreciated that, depending on the nature of the taxonomy being used,there may be various degrees of sub-classification. Thus, a taxonomycould include sub-classes, where the instantiations fall under asub-class.

Buyers and sellers may use the EPN in e-commerce documents within atrading community to represent products they are buying and selling.

CPTIs and EPNs may enable OEMs 208, OEDs and CEMs 220 (FIG. 2) to easilycollaborate with component manufacturers 216 and distributors 206, 204to quickly determine FFF equivalency. This may enable procuring entitiesto purchase electronic components and for sellers to more easilydirectly sell electronic components.

CPTI may enable CEMs 220 to rationalize multiple AMPLs and benefit frominterchangeability of procured components when manufacturing productsfor the CEMs' multiple customers.

A “collaborative taxonomy” is a catalog taxonomy created together bymembers of a trading community, usually starting with a base standardtaxonomy (e.g., RosettaNet's RNTD, UNSPSC, eClass, BMEcat, etc.), andthen deleting and/or adding classes, characteristics and values.

In contrast, the RosettaNet Technical Dictionary (RNTD) is anuninstantiated taxonomy, comprised of Classes, Property Sets,Properties, and Property Value Expressions. The RNTD has class IDs,where DRAM is a “class.” A virtually infinite number of instantiationscould be generated from an RNTD class taxonomy. Manufacturers anddistributors offer hundreds of variations of DRAM products, each withtheir own part number. Through categorization into the RNTD taxonomy,each DRAM product may generate separate instantiations, none of whichmight be FFF equivalent.

III. In a block 334, an exchange operator may subsequently catalog (orcategorize) EPNs, related taxonomies and instantiations into a tradingexchange-based, web accessible, electronic catalog (e-catalog).

FIG. 10 illustrates an electronic catalog 1010, which includes ataxonomy 1000, at least one taxonomy instantiation 1002, a search engine1004 and at least one part number 1006 associated with the taxonomyinstantiation 1002.

The “catalog taxonomy” is the catalog's complete set of classes (a.k.a.categories) 1012, characteristics (a.k.a. attributes or properties)1014, value ranges 1016 and values 1018.

The “catalog search engine” 1004 is a software component that may (a)search the catalog's taxonomy (a.k.a. “search schema”) 1000 to findparts, prompted by user selection or specification of class 1012,characteristics 1014 and values 1018, and/or (b) find and displaytaxonomy instantiations 1002 as prompted by user selection or entry ofpart numbers 1006.

Members of the trading exchange community may access the search engine1004 and enter sets of characteristics and values for products thatbuyers would like to buy or sellers would like to sell. The searchengine 1004 may find any EPNs that already exist for the characteristicsand values.

Putting the taxonomy instantiation 1002, and the instantiation's EPN1006, into an exchange catalog 1010 enables a seller/recipient of ane-commerce document (e.g., an RFQ containing an EPN) to access thecatalog 1010 and display the taxonomy instantiation 1002 that correspondto the EPN 1006. Displaying the taxonomy instantiation 1002, whichcorresponds to an EPN 1006 appearing in an RFQ, may enable the seller ina buy-side hosted exchange to determine whether it has an FFF equivalentproduct upon which to base its response to the RFQ. A buyer in asell-side hosted exchange can use the taxonomy instantiation 1002 as abasis to determine whether it has an IPN whose requirements may befulfilled by a distributor or vendor who offers VPNs or MPNs with thesame instantiation as the EPN.

The resulting taxonomy instantiation 1002 used in the exchange catalog1010 may be expanded or modified as a result of each CPTI session. Thetaxonomy 1000 may be different than a taxonomy used in either thebuy-side participants' behind-the-firewall catalog (if they have one) orthe sell-side participants' catalog (if they have one). However, theresulting product taxonomy instantiation and exchange part number may beincorporated into the buy- and sell-side participants' BTF catalogs.

There may be several reasons for (I) the pre-commerce process ofcollaboration on the base taxonomy and (II) designation of an exchangepart number (EPN) to represent the collaborative taxonomy instantiation.

Collaboration may reduce or expand or edit the classes and properties ofthe standard taxonomy. Version 1.4 of the RNTD contains approximately741 classes, 2647 properties and 610 property sets. The class for DRAMincludes seven property sets, and 105 properties. It may be unlikelythat the range of products traded in any Private Trading Exchange (PTX)110 (FIG. 1) would span all classes of the RNTD. For any given class, itmay be unlikely that all properties of all property sets would berequired to specify a given product in the PTX. It may also be likelythat a given traded item might require a new class or additionalproperties than those available in the taxonomy before the collaborationprocess, which would result in the addition of a class and properties tothe baseline taxonomy.

So one of the first acts in preparing for PTX e-commerce sessions may befor the trading community to collaborate on the scope of the exchange'staxonomy, based on, for example, the RNTD. Since a given PTX wouldlikely only trade some subset of the total baseline taxonomy productarray, the collaborative taxonomy may only include instantiations ofcertain properties within a baseline taxonomy class. The instantiationsderived from the extracts represent products that are planned to betraded in the PTX.

Collaboration may expand the standard taxonomy. Buyers may want todefine requirements using properties not in the baseline standardtaxonomy version. Sellers may want to highlight differentiating featuresnot reflected in the current standard. Standard taxonomies may becomeobsolete. Any given taxonomy may evolve. For example, the current RNTDversion (2.0) is the fifth version of the dictionary. A standardtaxonomy might benefit from refinement or expansion, especially betweenstandard schema version releases.

RosettaNet has defined the RNTD as an industry standard taxonomy. Butvery few, if any, companies have precategorized their parts into thetaxonomy to the degree necessary to determine FFF equivalence. Also,taxonomy standards will always lag the evolving technology. Sellingentities in particular may feel that the standard taxonomy is notup-to-date or robust enough to accurately and completely describe whatthe selling entities wish to sell. However, using a standard taxonomy,like RNTD, as a baseline for collaboration in a CPTI process, would bemuch more productive than creating a taxonomy starting with nothing.While it requires upfront work for buyers and sellers to create acollaborative taxonomy to determine whether what a seller offers is FFFequivalent to what a buyer wants to buy via reference to collaborativetaxonomy instantiation, the process may be much more efficient if thetrading partners start with a baseline taxonomy, if one exists. It isreasonable to assume that the baseline RNTD for a given class, likeDRAM, might be 85 to 90% as specific as it would need to be. Formingcollaborative taxonomy instantiations may require up-front work by atleast some of the exchange participants as a prerequisite to automatede-commerce. However, once taxonomies and associated EPNs have beenestablished via CPTI, the problems resulting from different part numbersare solved, and buyers and sellers will no longer be constrained fromengaging in fully automated e-commerce processes in the buying andselling of direct- and stockable MRO materials.

A proprietary taxonomy may be used as a competitive advantage.Enterprises or consortiums may prefer a proprietary taxonomy to enableproduct differentiation or to reflect newly developed technology. Theenterprises and consortiums may accordingly regard the collaborative PTXtaxonomy to be a source of competitive advantage. The proprietarytaxonomy might be based on, or be an extension or refinement of, astandard taxonomy.

EPNs represent collaborative taxonomy instantiations. Pre-commercecollaboration enables participating companies to enter the resultingEPNs into their e-selling and e-procurement systems as material or part“master data.” The e-selling and e-procurement systems may generate andautomatically process e-commerce documents, e.g., RFQs and Quotations,which contain EPNs, if the EPNs have been entered as master data in theparticipating companies systems. Unless EPNs are entered as master datain the trading partners systems, EPNs in incoming e-commerce documentsmay not be processable electronically by the receiving e-procurement ande-selling systems.

“Master data” describes data (e.g., parts, vendors, customers, prices,costs, etc.) that is predefined in e-commerce and back office systems.The predefined master data enables the systems to process transactions(e.g., entering sales orders or purchase orders) that contain partnumbers. For example, if the part number 4711 has been defined in ane-selling system, and sales related master data for the material hasbeen maintained, then the e-selling system could automatically fill inthe price on a sales order after entry of the part number as a line itemin the sales order. As another example, if inventory management relatedmaster data for the part has been maintained in the system, then thesystem could automatically calculate the availability date of the itembased on information generated by applications (e.g., MRP or SCM) whichuse the inventory management related master data.

The availability of a standard taxonomy, like the RNTD, may provide ajump-start in developing a collaborative taxonomy, which can be modeledas a variant of a standard taxonomy.

FIG. 3B illustrates an example of using an SAP PLM System collaborativefolder as an environment for the collaborative product taxonomyinstantiation process as described in FIG. 3A between a buyer orprocurement side 300 and one or more sellers 312. FIGS. 3A-3B aredescribed below with FIGS. 4-6.

Collaborative Product Taxonomy Instantiation (CPTI) (FIG. 3A) mayrepresent a collaborative aspect of a broader process called CrossApplication Product Taxonomy Management (xPTM). (FIG. 5).

FIG. 5 illustrates an example of integrating a CPTI process (whiteboxes) into a broader set of functions called Cross Application ProductTaxonomy Management (xPTM) (i.e., xPTM includes an environment to managethe process of linking the EPN and the collaborative taxonomy intobuy-side 502, sell-side 504 and private trading exchange (PTX)applications. FIG. 5 shows CPTI and xPTM from the perspective of aprocurement private trading exchange (PTX), where the EPN and thecollaborative taxonomy are integrated with applications or components inbuyers' and sellers' enterprise computer systems 502, 504. xPTM and CPTImay also be applicable in a Consortia Trading Exchange (CTX) and/or asales private trading exchange (PTX). Stated generally, the presentinvention includes linking the collaborative taxonomy to back-endsystems that integrate with the data or information communicated. Morespecifically, in xPTM, the CPTI is used to integrate the IPN (InternalPart Number) and the MPNs (Manufacturers Part Numbers), and/or VPNs(Vendors Part Numbers) that are FFF equivalent of the IPN, into the AMPL(Approved Manufacturers Parts List). The AMPL is, in turn, integratedinto the following enterprise system product objects:

The BTF (Behind the Firewall) catalog, used by internal design andprocurement engineers to search, find and use existing IPNs andassociated AMPLs in new BOMs (Bills of Materials), where the new BOMrequires a component with the same FFF as an existing IPN.

Configurable product BOMs (Bills of Materials) where the AMPL's MPNs aremodeled as procurement variants in order to enable simulation in BW(Business Information Warehouse) of the effect of selecting alternativeMPNs within the AMPL in terms of resulting cost and lead time of theconfigurable equipment, whose BOM contains the AMPL.

FIG. 5 illustrates integrating the EPN and the collaborative taxonomyinto buy-side, sell-side and private trading exchange (PTX)applications.

The buy side 502 in FIG. 5 may include several software modules, such asan R/3 Materials Management (MM) module 506, Business InformationWarehouse (BW) module 508, Supply Chain Management (SCM) module 510, BTFcatalog management/search engine module 512, Supplier RelationshipManagement (SRM) module 514, Product Lifecycle Management (PLM) module516, and another OTF catalog management/search engine module 518. Thesemodules 506-522 may be available from SAP.

SAP R/3 is software supporting enterprise resource planning (ERP). SAPR/3 and the other modules are described at www.sap.com.

The catalog management part of the OTF catalog management/search engine518 may be an environment to collaboratively create a catalog producttaxonomy, instantiate the taxonomy, and then categorize the resultingEPN into the catalog taxonomy. The catalog search engine is softwarethat enables a user to find a part by specifying its characteristics orto display the characteristics of a specified part.

The PLM application 516 may be an environment to create product-relatedmaster data in an Enterprise Resource Planning (ERP) system. The PLM 516may also provide an environment to collaboratively specify acollaborative taxonomy, taxonomy instantiations, and for generation ofEPNs.

In FIG. 5, the CPTI process may include a start function 544, a downloadtaxonomy to collaborative-folder function 546, a collaborate on taxonomyfunction 548, a collaborative taxonomy (c-tax) file and folder 550,which holds the taxonomy, a create EPN for c-tax function 552, a catalogEPNs to c-tax function 554 and a resulting catalog of EPNs 556. Allother functions shown in FIG. 5 may be Cross Application ProductTaxonomy Management (xPTM) or enterprise system or e-selling ore-procurement functions. The PLM 516 c-Folder components andexchange-based catalog management/search engine 518 may be accessibleoutside the firewall (OTF) of the buy side enterprise system, on theexchange.

FIG. 6 illustrates the Cross Application Product Taxonomy Management(xPTM) process of FIG. 5 with a view of user roles. The followingscenario describes CPTI used in a procurement Private Trading Exchange(PTX), where the buying company 300 may seek additional sources ofsupply for a strategic component (e.g., DRAM).

In a block 546 in FIG. 5 (block 616 in FIG. 6), a buy-side procurementengineer 302 (FIG. 3B) secures or downloads a taxonomy to be used as abaseline taxonomy for collaboration. For example, the spreadsheetversion of the RosettaNet RNTD, version 1.4, may be downloadable fromwww.rosettanet.org. The buy-side procurement engineer 302 specifiesrelevant DRAM attributes among attributes provided by the baselinetaxonomy 304 and specifies values for the specified attributes.

In a block 548, the buy-side 502 and the sell-side 504 collaborate on ataxonomy. In blocks 604, 606 and 616 of FIG. 6, the design engineer andprocurement engineer may specify a schema attribute range andcollaborate 620 with a sell side 602 product manager on a taxonomyinstantiation. The buy-side procurement engineer 302 (FIG. 3B) publishesthe baseline taxonomy with specified relevant DRAM attributes 308 on theweb 311 via secure communication 307 with eXtensible Markup Language(XML) or xCBL. xCBL is an XML variant. XML is a technique to format adocument in a way that it can be read if processed by a computer. Thereare many XML variants.

In one configuration, the engineer 302 may use an SAP

Product Lifecycle Management (PLM) collaborative folder (c folder) 306,which is currently available from SAP, or a web-enabled collaborativecatalog maintenance environment. The PLM collaborative folder 306 is aweb accessible folder where documents can be stored, accessed andmodified by trading partners. The folder 306 may be used forcollaborative configuration and classification schemas. Storing thepublished baseline taxonomy with specified relevant DRAM attributes 308in a c-folder 306 enables sellers 312 to access and process (expand,reduce) the baseline taxonomy.

One or more sellers 312 may specify attributes of their DRAM productofferings in the collaborative taxonomy 304. The sellers 312 may want tospecify attributes not originally included in the baseline taxonomy. Aseller may have developed a product feature not yet in existence whenthe baseline taxonomy was created. The seller 312 adds the attributerepresenting the product feature to the buyer-specified collaborativetaxonomy stored in the c-folder 306 which the procurement engineer 302can also access.

In blocks 606, 618, 620 of FIG. 6 (and block 548 in FIG. 5), a buy-sidedesign engineer and/or the procurement engineer 302 and a sell-sideproduct manager collaborate on taxonomy characteristics and values.

After collaboration, the procurement engineer 302 evaluates the sellers'specified attributes, rationalizes these with the buyer providedattributes and specifies a resulting collaborative taxonomy (c-tax)instantiation 550. In a procurement exchange, the procurement engineer302 may finalize the collaborative taxonomy instantiation, which mayinclude additions or changes to the buyer-published initialcollaborative taxonomy as provided by one or more sellers 312. Theprocurement engineer 302 may decide to manage revisions to thecollaborative taxonomy instantiation by creating corresponding versionsor revision levels with PLM. In a sales market exchange, the process maybe the same except that the initial instantiation and collaborativetaxonomy instantiation finalization and revision is performed by theseller, with buyers proposing modifications. In a public market exchangeFIG. 8 the marketplace 802 administrator may provide the initialinstantiation and collaborative taxonomy instantiation finalization andrevision, with both buyers 800 and sellers 804 proposing modifications.Using the DRAM RNTD example above, an example of a collaborativetaxonomy instantiation may be derived:

RosettaNet Class=“XJA644” (DRAM) Technology=“CMOS”

Voltage [min]=“1.1”Voltage [max]=“5.5”

Rated Maximum Power=“GT 4 AND LT 6”

Operating Temperature [min]=“45”Operating Temperature [max]=“50”

Is Generic=“1”

Pin Count [min]=“20”Pin Count [max]=“24”

In a block 524 (FIG. 5) (block 608 in FIG. 6), a design engineer on thebuy side 502 may create one or more Internal Part Numbers (IPNs) or IPNmaterial masters.

In a block 534 (block 610), the design engineer may catalog IPNs to thecollaborative taxonomy (c-tax) instantiation, i.e., link an IPN to theclass, attributes and values of the c-tax.

In a block 612, the design engineer optionally uses Product LifecycleManagement (PLM) to create a version or revision level of the c-taxdocument 550.

In a block 536 (block 614), the design engineer specifies categoryattribute values of the IPNs and uses the c-Tax and IPNs to create anApproved Manufacturers Parts List (AMPL) structure.

In a block 564 (block 622), the sell-side product manager catalogs MPNsor VPNs to the c-Tax instantiation.

In a block 552, the design engineer or procurement engineer 302generates, designates or specifies an exchange part number (EPN), e.g.,“4711,” to represent the collaborative taxonomy instantiation. Thus, anexchange part number (EPN) is correlated with a collaborative taxonomyinstantiation. The part number may be a sequentially assigned number ormay be a part number designed to be recognizable as correlating to theinstantiation (sometimes know as an “intelligent” part number). Theprocurement engineer 302 may catalog an IPN as an EPN or generate aseparate EPN.

In a block 554, the procurement engineer 302 catalogs the EPN into anexchange catalog 1010 (FIG. 10) to produce a catalog 556 of EPNs 1006.An exchange catalog search engine 1004 may use the collaborativetaxonomy 1002 as the catalog search schema/taxonomy. The exchangecatalog search engine 1004 allows users to specify or select attributevalues from the C-tax 1000, which triggers the search engine 1004 toretrieve and display EPNs that have the specified attributes.

The collaborative taxonomy 1002 enables trading partners 302, 312 tofind EPNs where the desired form, fit, function (FFF) is known, but thecorresponding EPN is not. For example, if a trading partner 312 wants topromote a product for sale or generate a sales quotation in response toan RFQ, but does not know whether collaboration has already occurred orwhether a useable EPN already exists, the sell side trading partnerwould like to find out the attributes and values of an EPN. In anotherexample, a seller may want to know whether there is a part in thecatalog 1010 where the part is a DRAM component, with CMOS technology,with minimum voltage or 1.1, etc. The catalog search engine 1004 wouldfind the part based on the user specification or selection of theseattributes in the catalog.

The collaborative taxonomy 1002 enables trading partners 302, 312 tofind the taxonomy instantiation where the EPN is known but theassociated form, fit and function (FFF) are not. For example, if asupplier received an RFP/RFQ for “4711,” and wants to determine theassociated FFF, the supplier can enter the EPN 4711 into the catalogsearch engine prompting the catalog to display the attributes and valuesof 4711. If the EPN had already been cataloged into the supplier's BTFcatalog, the supplier would know the EPN and taxonomy instantiation.However, the supplier might not know the EPN in a scenario, for example,where the supplier is a new member of the trading community and was notable to participate in the original collaboration process.

FIG. 4 illustrates an example of multiple buy-side systems 402 andsell-side systems 406 that map an exchange part number (EPN 4711) to FFFequivalent BTF part numbers. In FIG. 4, buyers 408A-408C and sellers418A-418C may integrate the EPN into their respective enterprisecomputer systems by mapping the EPNs to their respective FFF equivalentIPNs, MPNs and VPNs.

In FIG. 4, the EPN 4711 has been mapped to the Internal Part Numbers(IPNs) 1234 and 7890 on the buy side 402 and to the MPNs ABCD and EFGHand the VPN WXYZ on the sell side 406. This mapping enables therespective enterprise systems on the buy and sell sides 402, 406 toautomatically translate to and from their respective IPNs, duringgeneration of purchasing documents, and MPNs and VPNs, during generationof sales documents. FIG. 4 also illustrates use of the EPN 4711 by theexchange-based systems 412, for example, for demand aggregation 414A,generation of Request for Quotations (RFQs) 414B, and auctioning/bidding414C.

Once the collaborative taxonomy 1000, the collaborative taxonomyinstantiation 1002 and associated EPN 1006 have been established,operators of a procurement PTX may use (a) the collaborative taxonomy1000 as a search schema in the catalog 1010 to search for part numberswith FFF specified by the taxonomy instantiation; (b) the EPN 1006 inRFQs to communicate to sellers the FFF requirements of the products tobe procured (the recipients can enter the EPN 1006 in the exchangecatalog 1010 to display the EPN's taxonomy instantiation 1002); (c) andthe EPN 1006 in the exchange auctioning and bidding system, DA/DB; (d)the taxonomy instantiation 1002 in an AMPL, in order to specify the FFFparameters by which the IPN, MPNs and VPNs within the AMPL are grouped.

The technique of CPTI and the resulting EPNs may be used to enableautomated translation from several different IPNs on the buy (demand)side into a single, common EPN, which can be used by multiple PTXapplications, such as demand aggregation 414A (FIG. 4), auctioning andbidding 414C, the generation and transmission of RFQs 414B, and thetranslation of EPNs in RFQs received by multiple sell side systems intoMPNs and VPNs within the sellers' systems.

On the procurement side 402, 502, a buyer 408 may model the EPN as amanufacturer's part number (MPN), which is linked to a buyer's internalpart number (IPN) via an approved manufacturers parts list (AMPL) 410Aor a purchasing information record 410C. As a result, purchasingdocuments generated by the buyers 408A-408C may contain both the IPN andthe EPN. The EPN is recognizable by the sellers' systems if the seller'ssystem (which may have participated in CPTI) can search the EPN in anexchange catalog or the seller's system has modeled the EPN as aCustomer Part Number (CPN). Additionally, the sell-side systemsgenerally may be able to automatically translate the EPN, modeled as aCPN, into the sellers' FFF equivalent MPN or VPN

In a block 540 (block 628), the procurement engineer on the buy-side 502may enter an EPN into an auctioning and bidding application 414C (FIG.4).

An Approved Vendors List (AVL) can refer to the same function as definedabove for AMPL.

On the sales side 406, 504, in a block 558 (block 624), the salesengineer or product manager either (a) engages in a CPTI process, andtakes the resulting EPN, or (b) selects EPNs of interest resulting fromearlier CPTI sessions from the exchange opportunity catalog 556, andenters/maps/model an EPN as a customer part number (CPN). The CPN may belinked to a seller's MPN or VPN. Boxes 416A-416C in FIG. 4 show EPNsmodeled as CPNs. The EPN-modeled-as-CPN may automatically translate intoa seller's Internal Part Number (IPN). The IPN may be a MPN, if theseller is a manufacturer 418A or 418B. The IPN may be a Vendor PartNumber (VPN), if the seller is a distributor 418C. TheEPN-modeled-as-CPN enables the recipient's e-selling or enterprisesystem to automatically translate an EPN received in an RFQ into theseller's MPN or VPN. In a block 560 (block 626), the seller may respondto auctioning and bidding system generated RFPs and RFQs.

In a block 538 (block 628), the procurement engineer may enter the EPNor MPNs or VPNs selected as a result of an auctioning and biddingprocess into an AMPL or AVL for the buyer's IPN.

FIG. 8 illustrates a market exchange scenario with buyers 800, amarketplace 802 and sellers 804 that use exchange part numbers (EPNs).In blocks 806 and 830, buyers 800 and sellers 804 collaborate (i.e.,expand or reduce) on an exchange schema and generate product taxonomyinstantiations. The market exchange operators may control themarketplace 802, which may be a web site. In a block 814, the marketexchange operator manages the exchange taxonomy (catalog schema) andtaxonomy instantiations resulting from the buyers' collaboration 806 andthe sellers' collaboration 830 on the baseline taxonomy, (e.g., theUNSPSC, eClass or RNTD, etc. taxonomy) in the marketplace 802. In ablock 816, the exchange operator 802 creates exchange product numbers(EPNs) and posts the EPNs as net changes to the marketplace/exchangecatalog.

In a block 808, the buyers 800 classify buyer's internal part numbers(IPNs) into the buyer's BTF catalog schema/taxonomy. In a block 818, themarketplace 802 operator publishes catalog updates or changes, which canbe downloaded to buyers' or sellers' BTF catalogs. In a block 832, thesellers 804 classify vendor part numbers (VPNs) (which could also becalled MPNs) into a supplier's BTF catalog schema/taxonomy. In a block834, the sellers 804 create a VPN/EPN link, e.g., where the EPN ismodeled in a Sales and Distribution (SD) system as a Customer PartNumber linked to a VPN.

In a block 810, the buyers 800 create a buyers' internal part number toEPN link, e.g., in an SAP Materials Management (MM) PurchasingInformation Record or AMPL. In a block 812, the buyers 800 generate aforecast of requirements for the buyers' internal part number. When abuyer sends the forecast requirements to the market exchange, thebuyer's system translates the buyer's internal part number into the EPN.In a block 820, the marketplace operator or a marketplace-based system802 aggregates all forecasts for the same EPN (coming perhaps fromdifferent buyers) in the marketplace systems environment 802. In a block822, the market exchange operators 802 may conduct an auction andgenerate an RFP or an RFQ. In a block 836, the sellers 804 check theiravailability status (also known as Available to Promise (ATP)) for theirpart number that is equivalent to the EPN in the RFP/RFQ document. In ablock 838, the sellers 804 may produce a proposal or quotation salesdocument to send to the buyers 800 either directly or via the exchange802.

FIG. 9 illustrates a schema (a.k.a. taxonomy) instantiation-based partnumber generation approach to multiple part numbers. All buy-side andsell-side participants may use EPNs. Buy-side systems that are on-rampsto the Market or Marketplace Exchange may map buyers' internal partnumbers (BPNs) with EPNs. One or multiple buy-side systems may have morethan one buyer internal part numbers for parts that are FFF equivalent.In this case, buyers separately map the FFF BPNs to the same FFFequivalent EPN. Examples of functions within a buy-side-of-the-exchangeprocurement system enabling BPN-to-EPN mapping are Purchase InformationRecords and Approved Manufacturers Parts List (AMPLs), as providedwithin SAP's R/3 Enterprise system. Most buy side systems may havesimilar functionality. Sell-side systems may map their internal sellerpart numbers (which may be MPNs if the seller is a manufacturer, orVPNs, if the seller is a distributor) to the EPN, where the EPN isentered as a Customer Part Number (CPN). An example of a function withina sell-side system enabling EPN to SPN mapping is the CustomerInformation Record, as provided within the R/3 Enterprise system. Mostsell side systems may have similar functionality. With the customer inforecord, the EPN would be modeled as a Customer Part Number (CPN).

A buyer 900 may have different divisions or have acquired a company orcompanies, which can result in the buyer using different part numbersBTF for FFF equivalent items. For example, the buyer might link inseparate purchasing information records or separate AMPLs Buyer PartNumber A (BPNA) 906A and BPNB 906B to the same EPN1. This internalmapping results in the buyer's system automatically translating thebuyers internal part numbers, for example, BPNA 906A and BPNB 906B, tothe same EPN, for example, EPN1. A marketplace 902 uses an EPN, forexample EPN1, which is a FFF equivalent to a Supplier Part Number Z(SPNZ) 910. Parts traded on the exchange require different EPNs, forexample EPN1, EPN2, or EPN3, when the EPNs have different FFF, asspecified by different corresponding taxonomy instantiations. EPN2 912is a FFF equivalent to BPNC 914, SPNY 916A and SPNX 916B. EPN3 is a FFFequivalent to BPND 920 and SPNW 922.

As a result of the technique of modeling FFF equivalent EPNs and linkingthese to IPNs in the buy-side systems purchasing info records or AMPLs(or the buy side system's equivalent functionality), exchange basedsystems, for example demand aggregation 414A (FIG. 4), can use a singlepart number, the EPN, because the on-ramp procurement systemsautomatically translate their IPNs to EPNs on commerce documents sent tothe market exchange environment. The technique of CPTI with resultingEPNs enables the same, universally understood EPN to appear on allcommerce documents, for example purchase orders (POs) and sales orders(SOs). Just as the buy-side procurement systems translate from IPNs toEPNs in outbound e-commerce documents through standard purchasinginformation records or AMPLs, the EPNs are translated to sellers' partnumbers (SPNs) on inbound commerce documents, through standard customerinformation record functionality. FIG. 11 illustrates a bill ofmaterials (BOM) structure 1100 for a parent item 1102 and an AMPL 1124for a component 1112 of the parent item 1102. In one example, the BOMstructure 1100 may be implemented behind-the-firewall by SAP R/3.

Thus, as shown above, the technique of CPTI and the Exchange Part Number(EPN) may serve as a semantics lynchpin in the supply chain by restoringthe semantic disconnect resulting from buyers and sellers havingdifferent, mutually incomprehensible part numbers for items which areFFF equivalents.

Although mySAP enterprise system examples are shown and described above,CPTI could be integrated in a network of heterogeneous e-selling ande-procurement and enterprise computer systems. E-selling ande-procurement and Enterprise computer systems generally allow users toestablish links and automatic conversion between internal part numbers(IPNs) and trading partners' part numbers. An example is the AMPL(Approved Manufacturers Parts List), where a user has linked an IPN fora component with several approved part numbers, including VPN1 1126A,MPN1 1126B, and EPN1 1126C (FIG. 11). After the user establishes thelink in the AMPL 1124, the buyer's procurement system can “translate”the buyer's IPN into a seller's part number 1126A or 1126B or an EPN1126C in purchasing documents sent to the seller. Another example is apurchasing information record that links an IPN with a vendor masterrecord. Enterprise systems generally have equivalent functionality thatworks on both the buy side and the sell side.

However, to enable the buyer to populate the AMPL 1124 or a purchasinginformation record, or the seller to populate a customer informationrecord, the buyer and seller have to communicate to determine that abuyer's IPN is an FFF equivalent to the seller's MPN. Without the CPTIprocess or an equivalent process where additional information isexchanged between buyers and sellers, neither buyer nor seller would beable to establish the link (or map) between their respective IPNs, VPNsand MPNs. Therefore, the automatic translation could not occur withoutCPTI or without some less efficient, less automated informationexchange.

With CPTI, buyers may populate either the AMPL or the purchasinginformation record with the Exchange Part Number (EPN). Sellers wouldpopulate the customer information record, or their systems' equivalentfunction, with the EPN. The respective buy-side and sell-side systemswould be able to automatically translate from the buyers' IPN to the EPNand from the EPN to the sellers' IPN, i.e., MPN or VPN.

A catalog content maintenance environment may be a software componentthat can create catalog content by maintaining a taxonomy 1000 (FIG. 10)and linking parts to taxonomy instantiations 1002. Taxonomy maintenancemay refer to selection or specification of (a) classes 1012 to beincluded in a catalog 1010, (b) characteristics 1014 to be included inclasses, and (c) values 1018 or ranges of values 1016 to be valid forcharacteristics 1014.

A “product taxonomy instantiation” is a taxonomy instantiation linked toa product (a.k.a. part).

Enterprises that utilize e-commerce technology (e-selling,e-procurement, public and private market exchanges) may have a largepotential return on investment (ROI) when using e-commerce technologyproducts to buy and sell direct and stockable MRO materials. However,the potential ROI in these technology products may not be fully realizedif the e-commerce processes are not fully automated, but rather requireparticipation of sales and procurement engineers to determine whethermaterials being traded are FFF equivalent.

The principles of CPTI may be applied to any manufacturing industry,such as semiconductors, computers, automotive, aerospace, defense,consumer goods, oil & gas, and apparel. Many industries are developingindustry-specific taxonomies, which are useable as base taxonomies forCPTI. These industries may have direct materials and/or stockablemaintenance, repair and overhaul (MRO) materials. The CPTI process mayenable customers to realize significant ROI in stockable MRO and directmaterials sales and procurement environments.

CPTI may be used by procurement engineers in purchasing companies, bysales engineers in selling companies and by operators of PTXs (PrivateTrading Exchanges).

A number of configurations have been described. Nevertheless, it will beunderstood that various modifications may be made without departing fromthe spirit and scope of the application. Accordingly, other embodimentsare within the scope of the following claims.

ACRONYMS

AML—approved manufacturer's listAMPL—approved manufacturer's parts listATP—available-to-promise

AVL—Approved Vendors List

EOMs—bill of materialsBTF—behind the firewall

BW—Business Information Warehouse

CEM—contract electronics manufacturerCMS—contract manufacturing servicesCPN—customer part numberCPTI—collaborative product taxonomy instantiationCPTM or c-PTM—collaborative product taxonomy managementCRM—customer relationship managementc-Tax—collaborative taxonomyCTX—consortia trading exchangeCW—content workbenchDAB—dynamic auctioning and biddingDB/DA—dynamic bidding, dynamic auctioning

EBP—Enterprise Buyer Professional

EMS—electronic manufacturing servicesEPI—exchange part identifierEPN—exchange part numberERP—enterprise resource planningFFF—form, fit, functionGTIN—global trade item numberIPC—Internet pricing and configuratorIPN—internal part number

IPC—SAP's Internet Pricing and Configuration KB—Knowledge Base MM—SAPR/3 Materials Management

MPN—manufacturer's part number

MRO—Maintenance, Repair and Operations MRP—Materials RequirementsPlanning

ODM—original design manufacturer—OEMs who no longer manufacture“in-house,” but rather outsource manufacture of designed equipment toCEMs (Contract Electronics Manufacturers).OED—Original equipment designerOEM—original equipment manufacturerOTF—outside of the firewallPEX—private exchange

PIPs—RosettaNet Partner Interface Processes

PLM—product lifecycle managementPM—plant maintenancePO—purchase order

PPV—Purchase Price Variance

PTX—private trading exchangeRFP—request for proposalRFQ—request for quotation

RNTD—RosettaNet Technical Dictionary

ROI—return on investmentROH—raw or purchasedSCE—sales configuration engineSCM—supply chain management

SD—Sales and Distribution

SFA—sales force automationSO—sales order

SRM—Supplier Relationship Management

VAD—value added distributorVPN—vendor's part numberxApp or X-App—cross applicationXML—eXtensible markup languagexPTM—cross-application Product Taxonomy Management

1-52. (canceled)
 53. An electronic commerce exchange being configured tocommunicate with at least one product procurement software applicationand at least one product sales software application, the procurementsoftware application having a first internal product identifier, thesales software application having a second internal product identifier,wherein the first and second product identifiers are different.
 54. Theelectronic commerce exchange of claim 53, wherein the procurement andsales software applications are separated by at least one firewall. 55.The electronic commerce exchange of claim 53, wherein the procurementsoftware application is configured to link the first internal productidentifier to an exchange part number, the exchange part numberrepresenting a collaborative taxonomy instantiation, the collaborativetaxonomy instantiation comprising form, fit and function characteristicsand values.
 56. The electronic commerce exchange of claim 53, beingconfigured to convert the first internal product identifier from theprocurement software application to an exchange part number.
 57. Theelectronic commerce exchange of claim 53, wherein the procurementsoftware application resides behind a first firewall and the salessoftware application resides behind a second firewall.
 58. Theelectronic commerce exchange of claim 53, further comprising a graphicaluser interface.
 59. The electronic commerce exchange of claim 53,further comprising an application program interface.
 60. The electroniccommerce exchange of claim 53, being configured to transfer anelectronic commerce document between the procurement and sales softwareapplications, the electronic commerce document containing an exchangepart number. 61.-76. (canceled)